Summary

The menu and the "Your gymnasts" page no longer disagree about who is logged in, "Log in" leads somewhere, and the project has a demo coach that the staff and the students who review it can use to save and delete things. The reasons for the login we have, everything we tried before choosing it, and what a real system would do are written in a new docs/AUTHENTICATION.md.

Closes #136, #138. (#137, accounts with passwords, is closed as not planned: see "Choices".)

What is in it

• One source of login state. AuthProvider asks the server me once, and useAuth() gives loading, authenticated or anonymous. The navbar, ProtectedRoute and the gymnasts page read it. The isLoggedIn useState in App.tsx is gone.
  • Before, a reload restored the session but the local value started as false, so a logged-in coach was sent away from /gymnasts; and the menu could say "Log out" while the page said "Log in".
  • ProtectedRoute waits while the answer is on its way ("Checking your login…") and does not send anyone away. The menu shows neither "Log in" nor "Log out" until the server has answered.
  • Log in and log out reset the Apollo store (resetStore), which asks me again, so the menu and the page change at once (clearStore only cleared the cache).
• A login page (/login). "Log in" in the menu goes there, and ProtectedRoute sends a visitor who is not logged in there with the page they wanted; after the login they go to it (only a path on this site; //evil.example is ignored). It has "Log in as the demo coach" (one click) and the form for a test coach of your own. The page says when it is served over http from another computer that it is not encrypted.
• Delete a gymnast from the gymnasts page, after a confirmation (Base UI alert dialog: focus stays in the dialog, Escape closes it). The dialog has a warning icon, "Delete gymnast", "You’ll permanently lose ’s:" with the list Profile, Routines and List of elements, and the buttons "No, keep it" (first, so Enter does not delete; a 2px edge that is at least 3:1 on the card) and "Yes, delete" (the red of the site). It has the same rounding as the other cards. The page tells the visitor ("… deleted.") and moves the focus to "Add gymnast".
• The gymnasts page follows the theme (dark mode). It used colors that had no dark value. It now uses theme values (new tokens for the circle, the field, the red and the "No, keep it" button), and a test computes the contrast of each pair from the real values in variables.css.
• Cards and buttons: bigger cards and text, a smaller circle, and a red trash button that is 48 by 48 CSS pixels (WCAG 2.2 asks for at least 24 by 24 at level AA and 44 by 44 at level AAA).
• Add form: the field with a save (tick) and a close (cross) at the end of it, as in the inline edit of the Atlassian Design System. No heading and no Cancel button; Enter saves and Escape closes. The label and the field are left-aligned.
• Name field: at most 70 characters can be typed or pasted (counted as Unicode characters, like the server), and at least 3 are needed to save. The 3 is a rule of the form only; the API still accepts 1–70 (written in docs/API.md).
• Titles: the page title has the same style as on the Elements page (the same rule in global.css).
• npm run db:demo makes the demo coach (demo@wag-planner.example) with three gymnasts, each with three elements from the catalog. Run again, it deletes what the demo coach has and puts the example data back; other coaches are never touched.
• Documentation: docs/AUTHENTICATION.md (new), and the README ("Try the app with the demo coach"), docs/API.md, docs/VM_SETUP.md, docs/UI_PLANS.md and docs/AI_USAGE.md.

Choices

docs/AUTHENTICATION.md has the full list of what we looked at (Google, https on the VM, a trusted certificate, passwords, encrypting the password ourselves with a sealed box or OPAQUE, a guest key, passkeys and magic links), what the test login does not protect, and what we would do in production.

Not done (still open)

• https on the course server. It is not available to the groups, and it did not work on our VM.
• Sign in with Google (the server side is in the draft PR feat: login with Google #71).
• The test login does not protect anyone's data: anyone can log in as any test coach. This is written on the login page and in the docs.
• An access token still works for up to 15 minutes after logout (see "What the server guarantees" in docs/API.md).

Testing

• npx tsc -b, npx eslint ., npx vite build and npx vitest run pass: 49 test files, 488 tests, none skipped (the backend tests run against a local database).
• New tests: ProtectedRoute (waits, lets in, sends to the login page with the page they wanted), LoginPage (demo coach, own test coach, from that leaves the site, errors, double click), isInsecureConnection, the delete button, resetDemoCoach (including that the test login finds the same coach), the session functions of the client, and one test of the whole path in src/App.flow.test.tsx: log in, save a gymnast, reload, log out, log in again and see the gymnast, delete it.
• Existing tests changed because the behaviour changed on purpose: the navbar (no isLoggedIn prop, "Log in" is a link), App.test.tsx (the old test clicked the local toggle; replaced by three tests that use the server's answer), and the gymnast page tests (they need the providers; names are matched exactly, because the delete button has the hidden text "Delete "). No expectation was removed to make a test pass; the test of the login form on the gymnasts page moved to LoginPage.test.tsx.
• Checked that the tests fail without the behaviour by breaking four things one at a time: waiting while the server has not answered, the same state for the menu and the page, a from that leaves the site, and resetting the store after a login. The last one was not caught by the flow test (it replaces the login functions), so client.test.ts was added, and fails when resetStore is replaced by clearStore.
• Not tried in a browser by hand in this PR.

🤖 Generated with Claude Code